Made some comments, mostly stylistic - and primarily just reviewed the alert type itself.

My biggest concern is the calculation of instanceIds in the alert executor in x-pack/plugins/alerting_builtins/server/alert_types/geo_threshold/geo_threshold.ts - it looks like it the id could change over time for the same entities, which you probably don't want to do. But, hard for me to say. It's possible that's what you want, or it's possible currLocation.shapeId is constant over time and so the instance id won't change over time. Reach out if you need more explanation ...

Please don't block merging this PR on my review, with @YulNaumenko & @pmuellr's reviews, I defer to them on this. :D

:elasticheart:

The geo-alert threshold introduces a great feature to users who rely on the stack for storing and monitoring location-based sensor data. It broadens the stack's support for IoT-Observability use-cases.

• On global or regional scale, consider monitoring vehicles like cars or ships with GPS and AIS sensor readings
• In a closed environment, consider monitoring assets with RFID

Thanks for putting all the pieces together on this!

Thank you for introducing the feature flag. It will help to do future development in a more incremental fashion, and give an opportunity for motivated users to test the framework.

There are some outstanding gaps that imho we should address in follow-on PRs. Listing these out here for reference, but will create separate issues for these as well:

• Feature completeness:

  • Introduce KQL filtering. Without it, users cannot narrow their entities or boundaries of interest. This is critical for operational use-cases (e.g. consider the analyst who would like to monitor this particular asset).
  • Enable "leaving" and generic "crossing"-conditions. These are similar to the entering-condition. Although not quite (e.g. The will require slight differences in how an AlertInstanceId should be represented).

• Increase resiliency with real-world data: this PR has been validated with synthetic data (either completely manufactured, or synthetic data derived from real world recordings). However, some initial testing seems to indicate, that not all edge-cases that woudl arise in real-world data would be handled:

  • known knowns:
    • the detection resolution is too coarse:
      • The interval window introduces both a maximum bound on the number of crossing-events that can be detected in a single tick. It either detects 0 or 1 entering event per track. These limitations are somewhat artifical since they are largely due to the behaviour on the JS-side (so not due to the update-resolution of the real world tracks, nor the results Kibana gets back from Elasticsearch).
        - the algorithm will miss multiple different shape crossings if they occur in the same interval (e.g. consider a track going X->Y->Z. The algo will only detect X->Y, even though ES returns sufficient information to determine X-Y and Y->Z)
        - the algorithm will miss “blips” (e.g. consider a track going X->Y->X in an interval. The algo will not detect this because it only compares against the previous locations instead of all locations it retrieves from ES)
    • The delayed-offset parameter does double duty.
      • The delayed-offset parameter was introduced to deal with laggy real-world data, to handle the cases where real-world events get logged with some delay (e.g. consider updates be logged between 2-3 minutes late. If the interval runs every 30s, they would always get missed). However, the delayed-offset is used to pad the interval detection window in the past. While this padding helps to capture the laggy-data, it significantly excarcerbates the issue mentioned above.
  • known unknowns
    • It is unclear how pauses and interruptions are handled. For example, consider a pause in updates from an entity, or when an alert is disabled. This is untested. Given that the look-back parameter is hardcoded to 5-minutes, it's reasonable to expect some issues.
    • The number of assets that can be tracked is limited to Elasticsearch’s agg max-bucket settings. This is also dependent on the number of boundaries. These limitations are not precisely known, and are not communicated in any way to the user (e.g. an analyst cannot know if a real-world crossing event was missed due to age-size limitations, known limitations of the algorithm (see avove), or bugs in the algorithm… even if they would like to find out).
  • The unknown unknowns
    • … ? …

• Polish

  • Icon doesn’t fit imho
  • event.CrossingTime is unix timestamp, which means it cannot be used in message-formatting (e.g. an analyst wants to generate an email-notification with “detected leaving of this asset at this time)

lgtm when green, super 🎉!